Repository navigation
LT-22854: Control the Avalonia interface font from the theme - #1196
johnml1135 wants to merge 7 commits into
Conversation
NUnit Tests 1 files ± 0 1 suites ±0 15m 23s ⏱️ + 6m 49s Results for commit c276827. ± Comparison against base commit d0d85cb. This pull request removes 9 and adds 183 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1196 +/- ##
==========================================
+ Coverage 39.88% 40.36% +0.47%
==========================================
Files 1542 1551 +9
Lines 355361 355667 +306
Branches 41320 41480 +160
==========================================
+ Hits 141753 143579 +1826
+ Misses 184253 182777 -1476
+ Partials 29355 29311 -44
🚀 New features to boost your workflow:
|
The five faces in use (Regular, Italic, Bold, BoldItalic, SemiBold) ship unmodified inside FwAvaloniaTheme.dll with the OFL text and a notice recording the SHA-256 of each file. Nothing registers or uses them yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The interface font is no longer left to the platform default. The FwUiFontFamily token names it, FwUiFont registers the bundled font collection and points Semi's DefaultFontFamily, ContentControlThemeFontFamily and SemiFontFamilyRegular at a stack of that font followed by the fallbacks the UI language needs. The default is Andika; fa, hi, ko, te and zh-CN get a Windows system font first and the SIL or Noto family second. The other UI languages are covered by the default itself. Data text keeps its writing-system font, and the writing-system abbreviation column is measured in the interface font. The token generator learns FontFamily entries. Tests cover each fallback language's sample string. Two tests that built Avalonia controls on the NUnit thread become AvaloniaTest, since the headless session owns the dispatcher. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ADR 0004 records that the theme controls the interface font, Andika as the proposed default and the alternatives, the Semi resource keys, the five faces, the unchanged sizes and the per-language fallback fonts. Two passages that still described the Fluent theme and its font now name the Semi theme and the FieldWorks interface font. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The nine committed dialog snapshots are regenerated with the interface in Andika. Lines are about 3 px taller at 11 px, so rows and dialogs grow a little; AssertNoCrowding still passes for every dialog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
f5874ae to
0921803
Compare
|
So my first thought on looking at this is how it will interact with the users ability to choose the UI font from the styles dialog. I'll do a code review on it, but I wanted to capture my thoughts first. |
jasonleenaylor
left a comment
There was a problem hiding this comment.
The token mechanism is a good shape, but please don't let the default raise the line height. Interface density is a feature of FieldWorks that nearly all users value, and Andika's 1.61 em line against Segoe UI's 1.33 makes every row and dialog taller. Pick a default that keeps today's line height, or bring the line-height tokens the ADR defers into this PR. Users with limited vision who need larger or taller text should get it through the user font setting in the inline comment, not through the default.
This review was assisted by Claude Opus 5.5.
| /// the order tried. A family that is not installed is skipped, so each list names a | ||
| /// Windows system font first and an SIL or Noto family second. Keyed by language code, so | ||
| /// every Chinese culture shares one list.</summary> | ||
| private static readonly Dictionary<string, string[]> FallbacksByLanguage = |
There was a problem hiding this comment.
FieldWorks already lets users choose a UI font: the UiElement style is listed in the Styles dialog (FwStylesDlg.cs:148 shows internal styles), with a font per writing system, and the WinForms views use it for UI text drawn in Views (FwBaseVc.MakeUiElementString, FilterBar.cs:930, the detail view's literal headings). Nothing in Avalonia reads it yet, and this table adds a second, fixed mechanism alongside it. It also misses ar, bn, km, ml, my, ne, ta, th and ur, which the installer ships (Installer.targets:98-127). The Avalonia interface font should integrate with that setting: take UiElement's font for the UI writing system, with the bundled font as the default when none is set, instead of a hard-coded fallback table.
There was a problem hiding this comment.
I've gone a different way on UiElement, deliberately. The interface font is chosen once at startup, from the theme and the UI language, and applies to the whole application. UiElement is a project style, so wiring it into Avalonia chrome would make menus and dialogs change font with whichever project is open. Avalonia's font resources are also application-wide, so a second project window would change the first. UiElement keeps its current job, UI-writing-system text drawn in Views, and writing-system text still uses its writing-system fonts. ADR 0004 records the decision.
The missing languages are fixed in c276827: ar, bn, km, ml, my, ne, ta, th and ur now have ordered fallbacks (Windows UI font first, then an SIL or Noto font, then the platform default). FwUiFontTests asserts the order for all 14 languages and shapes a sample for each. Those tests pass on Windows.
Larger text for users with limited vision isn't handled here. If it's needed, I'd make it an application-wide user setting rather than a project style.
Nine committed screenshots still showed the old Andika interface font. Regenerate exactly those nine by running the Avalonia dialog tests and copying the captures from Output/Snapshots, as the visual snapshot testing guide describes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
On density: the default is Segoe UI again, so line height is back to today's 1.33 em. Line-height tokens are still deferred. The nine dialog screenshots under |
Start here:
Src/Common/FwAvalonia/FwUiFont.csselects the application-wide interface font stack from the theme and startup UI language.Segoe UI is the default on Windows to preserve the density of the current interface. The stack adds named script fallbacks for the installer UI languages and ends with the platform default. The bundled Andika collection remains private; writing-system data continues to use its writing-system font.
The interface font is selected once for the application, so menus do not change with the open project. The
UiElementstyle continues to govern UI-writing-system text drawn in Views; it does not set Avalonia chrome. The question for review is whether the chosen families cover the supported installations without clipping or missing glyphs.Where to look
FwColorTokens.axamland ADR 0004: Segoe UI density and the app-wide decision.FwUiFont.FallbacksByLanguage: ordered Windows and SIL/Noto families.FwUiFontTests: ordered family selection and sample shaping for the installer languages.Not here: project-specific Avalonia interface fonts and line-height tokens. The nine dialog screenshots under
Docs/migration/baseline-screenshots/are regenerated with Segoe UI.Verification (Windows/x64, at the font commit before a comment-only rewrap):
.\build.ps1 -CommentHygiene -TokenHygiene: passed. Comment hygiene passes at the head.FwAvaloniaTests: 973 passed, 1 skipped, including allFwUiFontTests(ordered fallbacks for 14 languages and the sample-shaping cases).FwAvaloniaDialogsTests: 289 passed.LexTextControlsTests(Avalonia): 42 passed.test.ps1, and a live density and clipping check at other DPI settings.Next: review the refreshed screenshots and the fallback table.
Fallbacks and evidence
The prior ADR recorded Andika's 1.61 em line metric against 1.33 em for Segoe UI. Line-height tokens remain deferred. The added cases cover ar, bn, km, ml, my, ne, ta, th and ur. Sample character maps were inspected in locally installed Windows font files, but that does not prove shaping or availability on every supported Windows installation. Khmer UI was not installed on the test machine, so Khmer falls through to Noto Sans Khmer or the platform default there; its family name is not verified against Microsoft's documentation.
🤖 Generated with Claude Code
This change is